Development Roadmap
There are many people working on various elements of the Power TAC project. Some of it is code, some is documentation. This page is a place to discuss what needs to be done, by whom, in what order. We'll start with some categories and flesh them out as we go along. You are invited to edit this page if you know what you want to add/change, or contribute to the discussion if you think something is wrong or missing. This page should be updated as we work the project with priorities, task assignments (who is responsible for the various items), status (pending, in-process, complete), and links to details such as development blueprints. Documentation #Short overview document aimed at agent developers, requested by Manuela. Needed before end of October. #Full game specification, needed by end of January. #Article in a general-interest publication, such as CACM or IEEE Spectrum, announcing the competition and describing much of the material in the agent-oriented overview. A manuscript is finished and submitted. #A public website that describes the game, provides access to papers and specifications, and points to public servers and downloadable software. #Developer guide for broker framework. Architecture Decisions about overall structure of the system. Some of these decisions are already made, and many are yet to be decided. #Information architecture - purpose, content, and format of data shared by server, broker, and offline analysis tools. #Interaction architecture - how the server interacts with brokers, visualizers, and potential other tools. #Server platform #Server structure - major modules, plugin architecture, integration of Repast. #Broker platform #Broker framework - major modules, plugin architecture, integration of Repast. Kang has written up a high-level modular and behavioral description of a broker framework. #Game visualizer - dynamic display of broker and environment status during a run. #Game analyzer - visualize a game that's already been played, access data details in various useful ways. Server This is an approximate sequence, based on discussion 2010-09-22, updated 11-6. #Separate existing server into backend Spring-based simulation server and frontend Grails-based web app, connected with ActiveMQ. ##''Priority 1 is getting Spring-based simulation server up and running, which might initially read local config file for initialization. Carstenblock 12:47, November 9, 2010 (UTC) ##''Web front end is of lower priority as teams wanting to participate don't need it initially. Carstenblock 12:47, November 9, 2010 (UTC) ##''Server Database might not be necessary if competition data is completely logged into textfiles. Carstenblock 12:47, November 9, 2010 (UTC)'' #Work out basic Spring config that loads Repast agents and allows them to see each other in a network projection using local config file. Only Repast agents need to be accomodated; we do not need Repast charts and graphs. What about Repast logging? ##''Repast logging is basically log4j logging and thus should be integrated with the standard spring logging. The difficulty stems from RePast's static inclusion of log4j library in repast jar. Carstenblock 12:47, November 9, 2010 (UTC)'' ##''Spring OSGI bundles might provide the add-on / plugin functionality we are looking for. The question is if the repast listeners (basically the network projection) could be mapped to the OSGI service registry, which is normally used to expose certain service methods across different osgi bundles (aka repast modules).'' Carstenblock 12:47, November 9, 2010 (UTC) #Implement broker login, Repast-compatible simulation start. #Establish preliminary APIs for Wholesale Market, Distribution Utility, Broker Profile. #Implement simple PDA market for the Wholesale Market. Can we use the existing Liquidity Provider? Does that need to be a separate component? #Implement dummy Portfolio with fixed power consumption profile and prediction (using the KIT data server). #Get the Repast-based agent prototype working with the new server setup. #Implement Bank, Broker accounts. Update accounts based on Wholesale Market transactions. #Implement Distribution Utility to perform balancing accounting functions, interacting with Broker accounts in the Bank. #Define API for Customer models and Market Intelligence Service. #Implement Customer model that is sensitive to price changes. #Implement tariff that allows Broker to adjust prices, use this as at least part of fixed Broker endowment. #Update Broker prototype to adjust prices. #Add multiple Customer Population models and Market Intelligence Service. #Update history and prediction elements of Portfolio to use data from subscribed Customer models. #Update Broker prototype to offer multiple tariffs. #Update MIS to match Customers to tariffs, adjust Broker Portfolios, charge appropriate fees. #Implement Contract market and contract customers. #Make Customer models environment-sensitive, add Environment model. #Allow Brokers to get weather forecasts. For current development blueprints, see Server Blueprints. Broker framework Sample broker Visualizer Analyzer Category:planning